…one (#2335)

* Bump sqlite3 to 1.7.* series for Ruby 3.3

* Avoid using Gem::Specification to determine Sentry gems' paths

This will break users with bundler standalone setup.

* Update changelog

Also fix sqlite3 delayed_job CI

* Use Concurrent.usable_processor_count when it is available

It's a new API introduced in concurrent-ruby 1.3.1, which works better
in the container environment.

ruby-concurrency/concurrent-ruby#1038

Since there are gems like sorbet-runtime that still use older versions
of concurrent-ruby, we can't directly bump concurrent-ruby's requirement,
but need to check if the method is available before calling it.

* Update changelog

* Make links in `sentry-rails` gemspec more accurate

1. Add subdir with the gem.
2. Add specific version.

* Tranform gemspec metadata to a single Hash for `sentry-rails`

* Add bug tracker and documentation links into `sentry-rails` gemspec

* Make the same URI changes for `sentry-ruby` gemspec

* Make the same URI changes for `sentry-sidekiq` gemspec

* Make the same URI changes for `sentry-rescue` gemspec

* Make the same URI changes for `sentry-opentelemetry` gemspec

* Make the same URI changes for `sentry-delayed_job` gemspec

* fix changelogs

---------

Co-authored-by: Neel Shah <[email protected]>

* Suppress the unnecessary “unsupported options notice”

In `Scope#update_from_options()`, the method strips key-value pairs from
the `options` according to its parameters. When all keys in `options` are
supported, it still logs an “unsupported options notice” for an empty
`unsupported_option_keys` value with empty array literal in
`Sentry::Hub#capture_event`, like:
"Options [] are not supported and will not be applied to the event."

Example:

When calling `subject.capture_event(event, level: 'DEBUG')`, the
`capture_event` method should handle the options like this:

  # In this case, options == {:level=>'DEBUG'}
  unsupported_option_keys = scope.update_from_options(**options)
  # unsupported_option_keys should be [], but the following debug log will be shown
  # like "Options [] are not supported and will not be applied to the event."
  configuration.log_debug <<~MSG
    Options #{unsupported_option_keys} are not supported and will not be applied to the event.
    You may want to set them under the `extra` option.
  MSG

This patch changes the logic to check whether `unsupported_option_keys` is
empty before logging the notice, thus suppressing unnecessary logs.

Signed-off-by: moznion <[email protected]>

* Update sentry-ruby/spec/sentry/hub_spec.rb

---------

Signed-off-by: moznion <[email protected]>
Co-authored-by: Stan Lo <[email protected]>

…#2342)

* teardown_sentry_test helper should clear global even processors too

* Update changelog

* Don't fail fast on sentry-ruby jobs

* Support for Faraday instrumentation

* Require sentry/faraday by default

* Update CHANGELOG.md

* Use prepend in Faraday patch

* Simplify inserting faraday instrumentation

* Ensure none of the spans come from faraday when net/http is used

* Unify Net::HTTP and Faraday implementations
* Fix early return in Faraday when Sentry is not initialized

The original issue should be addressed in rmosolgo/graphql-ruby#5052

…ble_processor_count` (#2358)

* Include Sentry meta tag in the layout automatically
* Add --inject-meta option

* Fix rubocop setup (for some envs)

This makes it possible to use rubocop when working from inside a subdir.
It also fixes running rubocop from the root where it would actually use
the config that we have. Previously it would ignore it for some reason,
symlinking did the trick.

The rubocop-packaging was needed because something somewhere tries to
require it.

* [sentry-opentelemetry] rubocop -a --only Style/StringLiterals

* [sentry-rails] rubocop -a --only Style/StringLiterals

* [sentry-resque] rubocop -a --only Style/StringLiterals

* [sentry-sidekiq] rubocop -a --only Style/StringLiterals

* [delayed_job] pin activerecord-jdbcmysql-adapter to a specific sha for now

They bumped it to 9.1.0 and we need < 9

jruby/activerecord-jdbc-adapter@0a959b8

* [delayed_job] update sqlite for older rubies

this fixes the spec suite

* [sidekiq] fix specs

* [rails] support string errors in error reporter

* Update CHANGELOG

* [rails] log instead of raising when ErrorSubscriber fails

* [rails] fix spec

* Add Excon instrumentation

* Add missing specs

* Add CHANGELOG

* Fix Rubocop

* Fix spec support for Ruby < 3

* Update sentry-ruby/lib/sentry/excon/middleware.rb

Co-authored-by: Peter Solnica <[email protected]>

* Handle case for Excon 1+ with Hash as query

* Borrow Rack::Utils for building nested query

* Add one more specs for more advanced query building in Excon

* Fixes changelog

* Add new specs using the query parameter encoding

---------

Co-authored-by: Peter Solnica <[email protected]>

* Clear Rails' default backtrace filters from Sentry's backtrace cleaner

In Rails 7.2, Rails's backtrace cleaner, which sentry-rails' backtrace
cleaner inherits from, starts shortening gem's paths in backtraces. This
will prevent sentry-ruby's `Sentry::Backtrace` from handling them correctly,
which will result in issues like #2472.

This commit avoids the issue by clearing the default filters that
Sentry's backtrace cleaner inherits.

* Remove premature path-removal filter

This filter removes the project root part from the stacktrace, which prevents
sentry-ruby from retaining the correct absolute path of it.

)

…#2471)

* Update monitor_check_ins.rb
* Update CHANGELOG.md

---------

Co-authored-by: Peter Solnica <[email protected]>

* Default to internal_error rather than unknown_error

* Add tests for SpanProcessor#update_span_status

* Update CHANGELOG

* Update CHANGELOG.md

---------

Co-authored-by: Peter Solnica <[email protected]>

Currently, to make LSP servers like Ruby LSP properly work for gem, like
`sentry-ruby`, we need to open `/sentry-ruby` separately. When working on
tasks across multiple gems, like `sentry-ruby` and `sentry-rails`, it requires
2 separate VS Code windows while each can not interact with each other.

For example, when using `Debug` code lens provided by Ruby LSP in `sentry-rails`'s
tests, we can put breakpoints inside `sentry-rails`'s codebase, but not in `sentry-ruby`.

But if we open the project through this new workspace configuration file,
the multi-root workspace feature in VS Code will allow us to

- Access code across multiple gems
- Debug code with VS Code across multiple gems
- Run language servers independently for each gem

* Update tons of actions, with ruby 3.4

* Add code.namespace support, which is possible in 3.4

* Fixes backtracecleaner with inline templates

* Add CHANGELOG entry [ci skip]

Co-authored-by: Peter Solnica <[email protected]>

Closes #1632

* Ignore Sidekiq::JobRetry::Handled exception

* Style/TrailingCommaInArrayLiteral

* Update CHANGELOG

---------

Co-authored-by: Karl Entwistle <[email protected]>